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Abstract. We discuss the realization of evaluation strategies for the 
concurrent constraint-based functional language CCFL within the trans- 
lation schemata when compiling CCFL programs into the hierarchical 
graph rewriting language LMNtal. The support of LMNtal to express lo- 
cal computations and to describe the migration of processes and rules 
between local computation spaces allows a clear and simple encoding of 
typical evaluation strategies. 

1 Introduction 

The Concurrent Constraint Functional Language CCFL is a new multiparadigm 
constraint programming language combining the functional and the constraint- 
based paradigms. CCFL allows a pure functional programming style, but also the 
usage of constraints for the description and solution of problems with incomplete 
knowledge on the one hand and for the communication and synchronization of 
concurrent processes on the other hand. 

CCFL compiles into another multiparadigm language, i.e. the language LMNtal 
(pronounced "elemental") [UK05 I KIIMlHi] . LMNtal realizes a concurrent lan- 
guage model based on rewriting hierarchical graphs. One of its major aims is to 
unify various paradigms of computation and, thus, we chose LMNtal as a base 
model and target language for the CCFL compilation^] 

In this paper we discuss the implementation of evaluation strategies for CCFL 
within the compilation schemata. The support of LMNtal to express local com- 
putations and to describe the migration of processes and rules between local 
computation spaces allows the realization of typical evaluation strategies in a 
clear and simple way. 

Sect. [2] introduces into programming with CCFL and presents the main lan- 
guage features by example. Sect. [3] is dedicated to the compiler target language 
LMNtal and its evaluation principles. We discuss the encoding of evaluation 
strategies in Sect. [4} 

1 In [HL09] we took another approach with an abstract machine on a parallel multi- 
core architecture as compilation target and enabled even programming with typical 
parallelization patterns in CCFL. 



Program 2.1 A simple (functional) CCFL program 
def add x y — x + y 
def addOne = add 1 

def fac x = case x of 1 — > x ; 

n — > n * fac (n— 1) 



Program 2.2 CCFL: list length 

data List a — Nil \ Cons a ( List a) 

def length I — 

case I of Nil — > ; 

Cons x xs —> 1 + length xs 



2 Constraint-functional programming with CCFL 

The Concurrent Constraint-based functional Language CCFL combines con- 
cepts from the functional and the constraint-based paradigms. We briefly sketch 
on the main conceptual ideas. For a detailed presentation of CCFL's full syntax 
and semantics and application examples we refer to [HL09 Hof08 . 

Functional programming. CCFL's functional sub-language syntactically borrows 
from haskell. The language allows the typical constructs such as case- and let- 
expressions, function application, some predefined infix operations, constants, 
variables, and constructor terms, user-defined data types, higher-order functions 
and partial application and it has a polymorphic type system. 

Example 1. Prog. |2.1| shows a simple functional CCFL program. We stress on 
this example later again. The following derivation sequence uses a call-by-value 
strategy. As usual, we denote the n-fold application of the reduction relation 
by and its reflexive, transitive closure by We underline innermost 
redexes. Note, that the given sequence is one of several (equivalent) derivations. 

add (addOne ( 6+1 )) ( addOne 8 ) ~-^> add ( addOne 7 ) ( addOne 8 ) 
~» add ( addOne 7 ) ( add 1 8 ) -> 2 add ( addOne 7 ) 9 -> 3 add 8 9 -w 2 17 

Free variables. In CCFL, expressions may contain free variables. Function appli- 
cations with free variables are evaluated using the residuation principle |Smo93| , 
that is, function calls are suspended until the variables are bound to expressions 
such that a deterministic reduction is possible. For example, a function call 4 + x 
with free variable x will suspend. In contrast, consider Prog. pre defining the data 
type List a and a length-function on lists. To proceed with the computation of 
the expression length (Cons x (Cons 1 (Cons y Nil))) a concrete binding of the 
variables x and y is not necessary. The computation yields 3. 

In the following, we will use the HASKELL-typical notions for lists, i.e. [] and 
e.g. [1,6] for an empty and non-empty list, resp. , and " :" as the list constructor. 
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Program 2.3 CCFL: a game of dice 



1 fun game : : Int —> Int —> Int —> C 

2 def game x y n — 

3 case n of — > x =:= & y =:= ; 

4 m > with xl , yl , x2 , y2 : : Jni 

5 in dice xl & dice yl & 

6 s =:= xl + x2 & y =:= yl + y2 &£ 

7 game x2 y2 (m— 1) 

8 /im dice : : Jnt — > C 

9 de/ dice a; = 

10 member [1,2,3,4,5,6] x 

11 fun member :: a —> a —> C 

12 def member I x — 

13 I =:= y : ys —> x : y j 

14 Z =:= y: ys — > cose ys o/ [ — > x =:= y ; 

15 z: zs —> member ys x 



Constraint-based programming. CCFL features equality constraints on functional 
expressions, user-defined constraints, and conjunctions of these which enables the 
description of cooperating processes and non-deterministic behaviorj^] 

As an example consider Prog. |2.3| In lines [2}|7] we define a constraint ab- 
straction (or user-defined constraint, resp.) game. A constraint abstraction has 
a similar form like a functional definition. However, it is allowed to introduce 
free variables using the keyword with, the right-hand side of a constraint ab- 
straction may consist of several body alternatives the choice of which is decided 
by guards, and each of these alternatives is a conjunction of constraint atoms. 
A constraint always has result type C. 

The constraint abstraction game initiates a game between two players throw- 
ing the dice n times and reaching the overall values x and y, resp. 

In lines [5]-[7] we see a conjunction of constraints which are either applications 
of user-defined constraints, like ( dice xl) and (game x2 y2 (to— 1)), or equalities 
ei=:=e2 on functional expressions. 

Constraints represent processes to be evaluated concurrently and they com- 
municate and synchronize by shared variables. This is realized by suspending 
function calls (see above) and constraint applications in case of insufficiently 
instantiated variables. 

Guards in user-defined constraints enable to express non-determinism. For 
example the mem&er-constraint in lines |12f]15| non-deterministically chooses a 
value from a list. Since the match-constraints of the guards of both alternatives 



are the same (lines 13 and 14), i.e. / =:= y : ys, the alternatives are chosen 



non-deterministically which is used to simulate the dice. 



2 The integration of external constraint domains (and solvers) such as finite domain 
constraints or linear arithmetic constraints is discussed in Hof08 . 
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Note that alternatives by case-expressions as in lines [3] and [4] and alternatives 
by guarded expressions as in lines [13] and [14] are fundamentally different concepts. 
They do not only differ syntactically by using the keyword case— of and the 
separation mark ";" on the one hand and constraints as guards and the mark " |" 
on the other hand. Of course, the main difference is in the evaluation: While case- 
alternatives are tested sequentially ; guards are checked non-deterministically for 
entailment. 

The constraint evaluation in CCFL is based on the evaluation of the therein 
comprised functional expressions. Thus, we can restrict our presentation of eval- 
uation strategies to the reduction of functional expressions in this paper. 

Equality constraints are interpreted as strict. That is, the constraint 
e\ =:= e-i is satisfied , if both expressions can be reduced to the same ground 
data term |HAB + 06] , While a satisfiable equality constraint x —:— fexpr pro- 
duces a binding of the variable x to the functional expression fexpr and termi- 
nates with result value Success, an unsatisfiable equality is reduced to the value 
Fail representing an unsuccessful computation. 

CCFL is a concurrent language. Thus, constraints within conjunctions are 
evaluated concurrently. Concerning the functional sub-language of CCFL, we al- 
low the concurrent reduction of independent sub-expressions. 

3 LMNtal 

The hierarchical graph rewriting language LMNtal is the target language of 
the compilation of CCFL programs. One of its major aims is to "unify vari- 
ous paradigms of computation" [UK05] and, thus, it lent itself as base model 
and target language for the compilation of CCFL programs. We briefly introduce 
the principles of LMNtal by example, in particular the concepts necessary to ex- 
plain our approach in the following. For a detailed discussion of LMNtal's syntax, 
semantics, and usage see e.g. |UK05|UKHM06|LMNT0] . 

An LMNtal program describes a process consisting of atoms, cells, logical 
links, and rules. 

An atom p(X\, ...,X n ) has a name p and logical links X%, ...,X n which may 
connect to other atoms and build graphs in this way. For example, the atoms 
f(A,B,E), A = 7, g(D,B) are interconnected by the links A and B. Note that 
the links of an atom are ordered such that the above atoms can also be denoted 
by E = f(A,B), A = 7, B = g (D). As a shortened notation we may also write 
E = f(7,g(D)). A and B are inner links in this example; they cannot appear 
elsewhere because links are bilateral connections and can, thus, occur at most 
twice. 

A cell {a* ,r* , c* ,/*} encloses a process, i.e. atoms a, rules r (see below), 
and cells c within a membrane "{}" and it may encapsulate computations and 
express hierarchical graphs in this way. Links I may also appear in cells where 
they are used to interconnect with other cells and atoms. 
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Program 3.1 LMNtal: non-deterministic bubble sort 



1 L=[X,Y\L2] :- X> Y \ L=[Y,X\L2]. 

2 aList = [2,1,5,0,4,6,3]. 



Program 3.2 LMNtal: membranes to encapsulate computations 

1 {@r,{$p},$s} :- {{<§V, $p} ,$s}. 

2 {{@r,$p}/ ,$s} :- {@r,$p,$s}. 

3 {addOne(A,B) :- B = 1 + A. 

4 {addOne(2 ,D)} , { addOne (4 , 5) } } 



Example 2. Consider the following two cells. 

{addOne(A,B) :- B=l+A. E=5, {addOne(2,D)}}, {+E} 

The first cell encloses a rule addOne(A,B) :— 5=1+ A, an atom 5=5, and 
an inner cell {addOne(2,D)} enclosing an atom itself. The second (outer) cell 
just contains a link +E connecting into the first cell onto the value 5. 

Rules have the form Ihs :— rhs and they are used to describe the rewriting 
of graphs. Both, the left-hand side Ihs and the right-hand side rhs of a rule are 
process templates which may contain atoms, cells and rules and further special 
constructs (see e.g. |UKQ5j ) among them process contexts and rule contexts. 
Contexts may appear within a cell and they refer to the rest of the entities 
of this cell. Rule contexts @r are used to represent multisets of rules, process 
contexts $p represent multisets of cells and atoms. 



Consider the bubble sort rule and a list to sort in Prog. 3.1 as a first and 
simple example. In the bubble sort rule, link L connects to the graph [X, Y \L2] 
representing a list. Thus, [X, Y \L2] does not describe the beginning of a list but 
an arbitrary cutout such that the rule is in general applicable onto every list 
position where X > Y holds. Since LMNtal does not fix an evaluation strategy, 
the sorting process is non-deterministic. 

As a second example consider the LMNtal Prog. [372] Lines [3]-[4] show a cell, i.e. 
a process encapsulated by a membrane "{}". It consists of an arfdOne-rewrite 
rule in a PROLOG-like syntax and two cells each enclosing an addOne-aiom by 
membranes in line |3J A, B, D, E are links. The oddOne-rewrite rule cannot be 
applied on the addOne-atoms in line [4] because they are enclosed by extra mem- 
branes which prevent them from premature evaluation. The rules in lines [T] and 
[2j however, operate on a higher level and they allow to describe the shifting of 
the addOne-rule into the inner cells and backwards. At this, @r is a rule-context 
denoting a (multi)set of rules, and $p and $s are process-contexts which stand 
for (multi)sets of cells and atoms. The template {@r, $p}/ in line [2] has a sta- 
ble flag "/" which denotes that it can only match with a stable cell, i.e. a cell 
containing no applicable rules. 

In the current situation, the rule in line [I] is applicable to the cell of the 
lines [3}|4l where @r matches the addOne-iu\e : $p matches one of the inner 
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addOne-atoms and $s stands for the rest of the cell contents. A possible re- 
duction of the this cell (in the context of the rules of lines [l}j2]) is, thus, the 
following; we underline the elements reduced in the respective steps: 

{addOne(A, B) : -B = 1 + A. {addOne(2, D)}, {addOne(4, E)} } ~> (1) 

-B = l + A. addOne(4,E) }, {addOne(2 1 D)} } ^ a ddOne 



{ {addOne(A, B 
{ {addOne{A, B 
{ {addOne(A, B 



-B = 1 + A. E = l + A }, {addOne(2, D)} } ->+ 
-B = 1 + A. E = 5}, {addOne(2, D)} } 



The first inner cell is now stable such that no rule is applicable inside. Thus, 
we can apply the rule from line [2] 



{ {addOne(A,B) : -B = 1 + A. E = 5}, {addOne(2, D)} } 
{addOne(A, B) : -B = 1 + A. E = 5, {addOne(2, D)} } 



»(2) 



In this state, again the first outer rule (line [I]) is applicable which yields the 
following rewriting sequence and final state: 

{addOne(A, B) : -B = 1 + A. E = 5, {addOne(2, D)} } 

{ {addOne(A 7 B) : -B = 1 + A. addOne(2, D) }, E = 5} ~^ a ddOne 

{addOne(A, B) : -B = 1 + A. E = 5, D = 3} 

As one can see by the above example, LMNtal supports a PROLOG-like syntax. 
However, there are fundamental differences. Our example already demonstrated 
the use of process-contexts, rule-contexts, membrane enclosed cells, and the sta- 
ble flag. Different from other languages, the head of a rule may contain several 
atoms, even cells, rules, and contexts. A further important difference to other 
declarative languages are the logical links of LMNtal. What one may hold for vari- 
ables in our program, i.e. A, B, D, E, are actually links. Their intended meaning 
strongly differs from that of variables. Declarative variables stand for particular 
expressions or values and, once bound, they stay bound throughout the compu- 
tation and are indistinguishable from their value. Links in LMNtal also connect to 
a structure or value. However, link connections may change. While this is similar 
to imperative variables, links are used to interconnect exactly two atoms, two 
cells, or an atom and a cell to build graphs and they have, thus, at most two 
occurrences. The links D and E in the above example occur only once and, thus, 
link to the outside environment. In rules, logical links must occur exactly twice. 

Semantically, LMNtal is a concurrent language realizing graph rewriting. It 
inherits properties from concurrent logic languages. LMNtal does not support 
evaluation strategies. The rule choice is non-deterministic, but can be controlled 



by guards (used e.g. in Prog. 4.1 for the /ac-rules, see below). 

As shown in the example, the encapsulation of processes by membranes al- 
lows to express local computations, and it is possible to describe the migration 
of processes and rules between local computation spaces. We will use these tech- 
niques to implement evaluation strategies for CCFL. 
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Program 4.1 Intermediate LMNtal compilation result 



1 add(X, Y, VO) :- VO = X+Y. 

2 addOne(X,V0) :- app ( add ,1 , VI) , app ( VI , X, VO) . 

3 fac(X,V0) :- X =:= 1 | VO = 1. 

4 fac(X, VO) :- X =\= 1 j V0 = X*Vi, V2 = X-l, app(fac ,V2,V1) . 

5 app(fac , VI) :- fac(Vl). 

6 appifac , VI, V2) :- /ac(Vi,V8). 

7 ... 

8 app(add, VI, V2, V3) :- add(Vl , V8, V3) . 

9 app( VS, VS, V£) , add( Vi, F,8) :- add ( V? , V9, V£ ) . 
10 ... 



4 Encoding evaluation strategies 



Now, we discuss the compilation of CCFL programs into LMNtal code. We start 
with a presentation of the general translation schemata and show the realization 
of a call-by-value strategy and an outermost evaluation strategy subsequently. 

Our compilation schemata are partially based on translation techniques 
|Nai91 Nai96 War82] for functional into logic languages. 

A CCFL function definition is translated into a set of LMNtal rules. CCFL data 
elements and variables are represented and processed by means of certain heap 
data structures during run-time. However, to clarify the presentation in this 
section, we represent CCFL variables directly by LMNtal link^J instead and data 
structures by LMNtal atoms. For a detailed discussion of the heap data structures 
sec [Hof08]. CCFL infix operations are mapped onto their LMNtal counterparts. 
Function applications are realized by an atom app (...) and an according app-ru\e 
which is also used for higher-order function application and partial application 
as discussed in |Hof08| . Case-expressions generate extra LMNtal rules for pattern 
matching, let-constructs are straightforwardly realized by equalities. 



Example 3. Consider the CCFL Prog. 2.1 It compiles into the (simplified) LMNtal 



code given in Prog. 4.1 (not yet taking an evaluation strategy into consideration). 

The additional link arguments VO of the add-, addOne-, and /ac-rewrite rules 
are used to access the result of the rule application which is necessary because 
LMNtal explicitly deals with graphs while a computation with a (constraint-) 
functional language like CCFL yields an expression as a result. The two fac rules 
result from the case distinction in the according CCFL function. 

Note that the right-hand side of the addOne rule in line [2] represents the 
LMNtal expression (app (app add 1) X) resulting from the CCFL addOne defini- 
tion in Prog. [2~T] by ry-enrichment. 



3 Moreover, we tolerate n-fold occurrences of links in rules, where n/2. This is also 
not conform with LMNtal, where links must occur exactly twice in a rule, but the 
problem disappears with the introduction of heap data structures as well. 
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The rules of lines |5]|l0| are a cutout of the rule set generated to handle function 
application including higher-order functions and partial application (according 
to a schema adapted from Nai96 War82 ). Thus, in these rules the root symbols 
appear with different arities. 

LMNtal evaluates non-deterministically, and it does a priori not support cer- 
tain evaluation strategies. Thus, the control of the order of the sub-expression 
evaluation for CCFL is integrated into the generated LMNtal code. We realized 
code generation schemata for different evaluation strategies for CCFL by encap- 
sulating computations by membranes using similar ideas as demonstrated in 
Prog. |3.2| We discuss the realization of a call-by- value and an outermost reduc- 
tion strategies in the following. 

A call-by-value strategy To realize evaluation strategies expressions are destruc- 
tured into sub-expressions which are encapsulated by membranes and inter- 
connected by links. These links allow to express dependencies between sub- 
expressions on the one hand, but to hold the computations apart from each 
other, on the other hand. Consider the CCFL application 

add (addOne (6+1)) (addOne 8) (1) 

from Example [T] It is destructured and yields the following LMNtal atoms: 

Z = add (X, Y), X = addOne (W), W= 6+1, Y = addOne (8) 

or in an equivalent notation, resp.: 

add (X,Y,Z), addOne (W,X), W= 6+1, addOne (8,7) (2) 

The idea to realize a call-by- value evaluation strategy is now provide the 
expressions to be reduced first (i.e. the inner calls W = 6+1 and addOne (8, Y)) 
with the ruleset and to delay the outer calls by holding them apart from the 
rules until the computation of the inner redexes they depend on is finished. 
To enable a concurrent computation of independent inner sub-expressions as 
discussed in Example [T] we must assign each independent inner expression or 
atom, resp., a separate membrane (including a copy of the rules). This yields 
the following structure (where every atom is held within separate membranes 
for organizational reasons). 

{{add{X,Y,Z)}} {{addOne{ W,X)}} {©rules, {W=6+l}} {Qrules, {addOne{8,Y)}} (3) 

Fig. [I] visualizes an evaluation of ^ using a call-by- value strategy with con- 
current evaluation of independent sub-expressions. Reduction step numbers are 
given in brackets at the right margin. Membranes are represented as enclosing 
ellipses. Interdependencies of atoms by links control the order of the evaluation 
and they are represented by arrows. 

In the initial state, the atoms W=6+l and addOne(8, Y) are inner redexes 
to be reduced first. We mark these by a gray color. They are provided with the 
LMNtal rules @rules generated from the CCFL program. The atoms add(X, Y,Z) 
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(1) 



(2) 



(3,4,5) 



(0) 



Fig. 1. A call- by- value computation sequence 



and addOne( W,X) represent outer calls to be delayed until the computation of 
their inner sub-expressions have been finished. Thus, we put them into extra 
protecting membranes. 

To control the order of sub-expression evaluation we need three things: 



i. the destructured expression as given in pL 

ii. LMNtal rules (denoted by ©rules in FigTTll) generated from the CCFL pro- 
gram: These rules take the destructuring of expressions into consideration 
and realize local call- by- value evaluations. 

iii. a general LMNtal ruleset reorganizing the computation spaces in case that 
local computations are finished. 

(i) and (ii) The destructuring of expressions in LMNtal rules (ii) generated 
from the CCFL program is handled similarly to (i) as discussed above. Prog. 4.2 
shows the LMNtal code generated from Prog. [2~T] taking the intended call- by- value 
evaluation into consideration. 

The LMNtal rules' right-hand sides consist of cells containing the destructured 
expressions. Outermost expressions are encapsulated by extra membranes to pro- 
tect them against premature evaluation as necessary for an innermost strategy. 
This effect is observable for the addOne-rvle in line [2] and the second /ac-rule in 
line [5j while for the other rules the flat term structure of the right-hand sides 
of the CCFL functions is just carried over to the generated LMNtal rules. To sim- 
plify the presentation in Fig. [T] however, we inlined the app-calls for function 
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Program 4.2 Generated LMNtal code for a call-by-value strategy 



1 { add(X, Y, VO) , $p} { VO = X+Y, $p } . 

2 { addOne(X, VO) , $p} :- { app ( add ,1 , VI)} , {{ app (VI , X, VO) , $p } } . 

3 {fac(X, VO), $p} :- X =:= 1 | {VO = 1 , $p} . 

4 {fac (X, VO) , $p} :- X =\= 1 

5 = $p}}, {V2 = X-1}, {{app(fac ,V2,V1)}} . 

6 {app(fac ,V1) , $p} {/oc(Vl), $P } . 

7 {app{fac , VI, V2) , $p} :- {/ac(yj,yS), 

8 ... 



Program 4.3 LMNtal code for a call-by-value strategy, simplified version 

1 { add(X, Y, VO) , $p} :- { VO = X+Y, $p } . 

2 { addOne(X, VO) , $p} :- { add (1 ,X, VO) , $p} . 

3 {fac (X, VO) , $p} :- X =:= 1 | {1/0=1, 

4 {/oc(X, V0), $p} :- X =\= 1 

5 {{V0 = X*V1, $p}}, {V2=X~1}, {{fac(V2,Vl)}}. 



applications (e.g. we applied the app- rule of line [7] on the call app (fac, V2,Vi) 
of line [5]) and used instead of Prog. 4.2 the accordingly simplified Prog. 4.3 



(Hi) The reorganization of computation spaces for the call-by- value strategy 
is mainly realized by two LMNtal rules given in Prog. |4.4| They are visualized 
in Fig. [2] for better understanding. These rules organize the evaluation of outer 
calls when the inner redexes they depend on have been completely reduced. In 
the following, we discuss the rules semantics by means of Fig. [2j 




Fig. 2. LMNtal: rules emulating a call-by-value strategy 



Both rules, (A) and (B), are only applicable when the cell 
{©rules, {p (..., L)}} is stable, i.e. the rules cannot be applied on the 
atom p (..., L) (or L=p(...), resp.) further. For rule (A), the atom q (..., L ,...) 
does not contain any further link connected to a process representing a 
sub-expression evaluation. Thus, both atoms are ready for their combined 
evaluation, and they are put into one computation cell or space, resp., together 
with the rules. An example for the application of this rule is the computation 
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Program 4.4 LMNtal rules to control the reorganization of computation spaces 
for a call-by- value reduction of the CCFL compilation result 

1 ruleA@@ 

2 { ©rules, {$procs_p , +L, inLtnks_(0)} }/, 

3 { {Sprocs_q , —L, inLinks _ (N)} } : — 

4 N =:= 1 | { ©rules, {$procS-p , $procs_q , mLinks_(0)} }. 

5 ruleB@@ 

6 { ©rules, {Sprocs_p , +L, inLinks_ (0)} }/, 

7 { {$procs_q , —L, inLinks - (N)} } : — 

8 TV > 1 j { { $procs-p , $procs_q , inLinks. (M) , M= N—l} }. 



Program 4.5 LMNtal compilation result for an outermost strategy 

1 {fac(X,V0), $p} :- X =:= 1 | { V0 = 1, $p} . 

2 {fac(X, V0) , $p} :- X =\= 1 

3 {V0 = X*V1, $p}, {{V2 = X-l}}, {{fac(V2, VI)}}. 



step (2) in Fig. [Tj where the atoms W—7 and addOne( W,X) are brought 
together into one membrane and join into the atom addOne(7,X). 

Rule (B) describes the case that the atom q (..., L ,...) does contain at least 
one further link connected to a process itself under evaluation. These represent 
sub-expressions of q (..., L ,...) or inner redexes, resp., and are denoted by in- 
going links resp. arrows in Fig. Thus, while p (..., L) and q (..., L ,...) can 



be combined in one membrane, they are not ready for evaluation yet such that 
we omit the rules ©rules on the right-hand side here. An example is step (6) in 
Fig. [TJ the atoms add{X,Y,Z) and Y=9 are combined in one membrane but not 
provided with the rules. 

An outermost strategy For call-by-name and lazy evaluations the computation 
proceeds on the outermost level. As we will see in the following, thus, copying 
of the rule-set, like for the innermost strategy, (which may become expensive) is 
not necessary. Besides, the mechanisms are are quite similar. 



Consider the CCFL faculty function from Prog. 2.1 The (simplified) LMNtal 



compilation result taking an outermost strategy into consideration is given in 



Prog. 4.5 In contrast to Prog. 4.3 now innermost expressions on the right-hand 
sides are encapsulated by extra membranes to protect them against premature 
evaluation. (The flat term structure of the right-hand sides of the CCFL functions 
add and addOne is again just carried over to the generated LMNtal rules and 



yields the same results as in Prog. 4.3) 



Fig. [3] shows an outermost evaluation sequence of an LMNtal process corre- 
sponding to the CCFL expression add (addOne (6+1)) (addOne 8). We did de- 
note the ruleset ©rules only in the first computation state; there is in general 
only one copy and it resides on the top level where the computation executes. An 



4 An outgoing link from q (..., L ,...) would accordingly represent its parent expres- 
sion. Such links are allowed, of course, but omitted in Fig.|2]for easier understanding. 
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rules 




CD 



(2,3) 



(4) 



(5,...) 



Fig. 3. An outermost computation sequence 



evaluation sequence for an LMNtal process corresponding to the CCFL expression 
fac (addOne (addOne 3)) is shown in Fig. [5} 

We show two examples of evaluation sequences to allow a direct comparison 
between the two evaluation sequences in Fig. [1] and Fig. [3] for the expression 
add (addOne (6+1)) (addOne 8) on the one hand, but to illustrate a particular 
aspect of outermost strategies (i.e. the unprotect-protect mechanism as described 
in particular for the sequence in Fig. [5] below) , too. 

The two main rules realizing the outermost evaluation are given in Fig. [4j 
We mark cells on the outermost level, i.e. cells to be reduced first, by the dark 
gray color as before. Again, the rules are only applicable if the cells with dark 
gray color are stable, i.e. they cannot be reduced further. 

Rule (C) lifts the ("first") inner expression p (..., L) on the evaluation level 
in case that the outermost term q (..., L ,...) is not (yet) reducible. However, for 
such (light-gray marked) sub-expressions (and except for arithmetic expressions) 
only one reduction step is allowed before protecting its result again by an extra 
membrane. This is realized by a variant of each rule of Prog. 4.5 (not shown 



there). Rule (C) is applied e.g. in the first computation step of Fig. [5 Afterwards 
the described unprotect-protect-mechanism applies. In steps (3) and (4) of Fig. [5] 
rule (C) is applied even twice which allows to make a reduction step onto the 
inner redex addOne(3, Y) in step (6). For the applications of rule (C) in e.g. step 
(4) of Fig. [5] and (2,3) in Fig.|3]the unprotect-protect mechanism does not apply 
because the outermost expressions are arithmetic ones, here, such that we use 
rule (D) afterwards. 
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Fig. 4. LMNtal: rules emulating an outermost strategy 



Program 4.6 LMNtal compilation result: list length 

length(L,VO) , nil(L) :- ... 
length(L,VO) , cons(X,XS,L) :- ... 



Rule (D) can only be applied on expressions with arithmetic built-in opera- 
tors as root. Because, in this case, the outermost term can only be evaluated if 
the inner expressions are completely evaluated, we lift them onto the outermost 
level, in general. The rule is applied in the step 4 of Fig. [3] and step 5 of Fig. [5] 

We realized a call-by-name strategy using the presented approach. The en- 
coding of a call-by-need strategy is possible by additionally introducing heap 
data structures as anyway needed to deal with free variables and constraints in 
CCFL (see above and |Hof0 8]). These allow sharing as needed for lazy evaluation. 



Residuation Function applications in CCFL may contain free variables. In such a 
case, we apply the residuation principle [Smo93 (see above). This is realized in 
the resulting LMNtal program by according atoms in the rules left-hand sides as 



in the following example (or guards resp. as e.g. in Prog. 4.1 for the /ac-rules) 
checking for concerning variable bindings. 



Example 4- Consider again the CCFL Prog. |2.2| defining a length-function. 
Prog. |4.6| shows a cut-out of the generated LMNtal program. From a not suf- 
ficiently instantiated CCFL expression ( length y) the compiler generates an ac- 
cording LMNtal atom length ( Y, V). The LMNtal evaluation of this process to- 
gether with Prog. [4~6| suspends as long as there is no connection of the link Fto 
an appropriate atom or graph, i.e. we need an atom nil ( Y) or cons (H,T,Y). 



5 Conclusion 



We discussed the realization of typical evaluation strategies for functional pro- 
grams based on hierarchical graph rewriting. The control of sub-expression eval- 
uation was built into the translation schemata when compiling CCFL programs 
into the graph rewriting language LMNtal. LMNtal is a concurrent language not 
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Fig. 5. An outermost computation sequence, II 



supporting strategies a priori. However, the abilities of LMNtal to express hier- 
archical computation spaces and to migrate processes and rules between them 
enables a clear and simple strategy control. 

Ueda [Ued08b|Ued08al presents encodings of the pure lambda calculus and 
the ambient calculus, resp., using LMNtal. Like in our approach, the membrane 
construct of LMNtal plays an essential role for the encoding and allows a signifi- 
cantly simpler than previous encodings, like e.g. that of the lambda calculus by 
Sinot |Sin05j based on token passing in interaction nets. In [BFR05 Banatre, 
Fradet, and Randenac identify a basic calculus 70 containing the very essence 
of the chemical calculus and which - similar to LMNtal - is based on multiset 
rewriting. They show an encoding of the strict A-calculus which is straightfor- 
ward because of the strict nature of 70 and state that an encoding of a call-by- 
name A-calculus is possible too, but more involved. In contrast, LMNtal a priori 
does not support certain evaluation strategies. Instead, LMNtal offers extended 
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features like the rewriting of rules and graph hierarchies which allows to en- 
capsulate and migrate computations which was highly used in our modelling of 
evaluation strategies as presented in the paper. 
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